\section{Planificaci\'on y seguimiento}

	En esta secci\'on documentaremos el avance en nuestro proyceto y contaremos nuestra forma particular de trabajo. Explicaremos tambi\'en algunos inconvenientes que tuvimos con respecto a las stories planificadas y su correlaci\'on con el dise\~no finalmente implementado. Mostraremos adem\'as c\'omo las situaciones antes mencionadas se reflejan en el burndown chart para la iteraci\'on planificada.
	
	
	\begin{figure}[!h]
\centering
\includegraphics[scale=0.6]{./diagramas/burndownchart.png}
\caption{Burndown Chart para nuestra iteraci\'on.}
\end{figure}


\subsection{Nuestra forma de trabajo y definici\'on de iteraciones}
	
	Nos parece interesante mencionar nuestra forma y tiempos particulares de trabajo ya que hace que la metodolog\'ia tradicional de trabajo con SCRUM no sea aplicable directamente a nuestra situaci\'on. 
	
	Los cuatro integrantes de nuestro grupo trabajamos full time y tambi\'en cursamos, en general, 2 materias en la facultad. Algunos de nosotros tambi\'en preparamos finales durante el desarrollo de la iteraci\'on. Por estas razones el tiempo disponible para el desarrollo de este trabajo pr\'actico se limit\'o a los fines de semana. 
	
	Considerando el poco tiempo disponible con el que contamos, decidimos dividir el scope del tp en una \'unica iteraci\'on.
	
	El alcance de la iteraci\'on, que fue presentado en la Entrega de Planificaci\'on,  fue documentado en la herramienta de seguimiento RallyDev. La informaci\'on completa puede obtenerse en la siguiente url:	\url{https://rally1.rallydev.com/#/7748712080d/detail/iteration/7779671771/scheduled}.
El backlog puede encontrarse aqui: \url{https://rally1.rallydev.com/#/7748712080d/backlog}.

\subsection{Avance hasta el momento de la primera entrega}

Cuando realizamos la separaci\'on en stories de los requerimientos para este TP nos dimos cuenta de que, para ser capaces de detectar todas las categor\'ias de insultos, un dise\~no apropiado era fundamental. Al planificar la iteraci\'on, el story de dise\~no fue al que le asignamos un mayor puntaje. 

Tambi\'en nos dimos cuenta de que la separaci\'on en stories estaba relacionada con el dise\~no que eligieramos ya que cuanto m\'as cercana fuera a la separaci\'on real de tareas, mejor se ver\'ia reflejado el avance en el proyecto. Por \'esta raz\'on dedicamos un tiempo a definir algunos aspectos iniciales del diseño antes de presentar la planificación de la iteración. Estas ideas estaban relacionadas al primer enfoque explicado en la sección anterior, por lo que resultaba natural que las stories constaran de detectar los distintos tipos de insultos.


\subsection{Elecci\'on del dise\~no}

El segundo fin de semana luego de la entrega, tras haber asistido a las clases de Dise\~no OO de la materia, nos juntamos todos los integrantes del grupo para decidir el dise\~no. Luego de plantearnos varias opciones y descartarlas por los problemas que explicamos en la primera secci\'on de \'este informe, nos decidimos por el enfoque de secuencias fon\'eticas.  Consideramos apropiado juntarnos todos para lograr ponernos de acuerdo y unir esfuerzos para llegar a un buen dise\~no, lo cual nos parece la parte fundamental y m\'as dif\'icil del Trabajo Pr\'actico.

La story de definici\'on del dise\~no era la m\'as larga de la iteracion, planificamos 13 puntos de los 33 totales.

Luego de validar con nuestro tutor el dise\~no cerramos la story. Observamos que al hacerlo, la linea de avance en el burndown chart se equipar\'o con la linea de base. 

\subsection{La implementaci\'on}

	Con el dise\~no fijado, la implementaci\'on fue r\'apida y sin inconvenientes. Como era sencillo agregar distintas estrategias de deformaci\'on de insultos, decidimos agrandar el scope planificado y finalmente nuestro sistema soporta todas las estrategias planteadas por la c\'atedra. 
	
	La definici\'on de la estructura general de nuestro c\'odigo se realiz\'o en una reunion conjunta m\'as corta que la anterior y los detalles los realizamos en paralelo, cada uno en nuestras casas. 
	
	Decidimos utilizar el lenguaje Ruby ya que, dentro de los lenguajes manejados por los integrantes del grupo, consideramos que es la implementación más pura del paradigma de objetos con que contábamos.

	Para la parte Web decidimos utilizar Sinatra, un Framework minimal para el desarrollo de aplicaciones web que nos permiti\'o realizar las acciones HTTP de forma sencilla. Ninguno de nosotros hab\'ia trabajado antes con Sinatra, pero no tuvimos mayores retrasos en el cronograma ya que las acciones que debimos realizar eran sencillas.
